Uber Scheduled Rides

Context

In the end of 2016, after merely less than 6-month effort of an ambitious brand refresh and engineering overhaul, Uber launched the new Rider app globally. The redesign successfully improved efficiency of the key user journey as well as brought the company under the media spotlight. However, as users were still getting used to the new flow, many key app metrics were underway to be restored to desired levels.

Challenge

“Scheduled rides” is one of the metrics that took a hit. In the old app, the entry point of Scheduled Rides was front and center without ambiguity. On the contrary, in the new app, the entry point of Scheduled Rides was minimized to an icon inside the “Where to” search bar in favor of simplicity. Because of this, we immediately noticed the discoverability issue as well as an increase in unintentional scheduling in the user feedback session.

Short-term improvement

Icon exploration

To disambiguate the entry point, one obvious low hanging fruit was to use a more descriptive symbol to represent scheduled rides rather than the existing generic calendar icon. I explored a range of visual concepts as well motion tooltips to bring clarity to the minimal icon. The final design led to a 4% increase in Scheduled Rides and was net position to the overall rides.

Integrate Scheduled Rides with the on-demand flow

Another angle to increase schedule rides was to think about where we could introduce additional entry points. The existing design separated the on-demand flow and scheduled rides flow into two branches via the scheduled-ride icon on the homepage, which means that if the user misses the icon entry point on the homepage, there is no easy way to get back into the scheduled rides flow down the funnel. Since most users don’t really think about scheduling a ride until they specify where to go in the on-demand flow, many of them weren’t even aware that it’s possible to schedule a ride.

To quickly validate whether a unified model works better than the existing branched flows of on-demand rides and scheduled rides, we launched an experiment of simply adding the scheduled-ride entry point next to the “request a ride” button in the on-demand flow, and the result was quite mind-blowing. We saw over 30% increase in scheduled rides!

Long-term vision

Insight | Riders’ two intents overlap

With the success of the previous experiment, it became obvious that the existing bipolar design between calling an on-demand ride and scheduling a ride was worth revisiting. Insights from data and user research also suggested that riders’ two intents of requesting a ride (on-demand v.s. scheduled rides) fall on a continuous spectrum, as opposed to being separate. 42.2% of scheduled rides happened when the rider is leaving soon in 5 minutes to 1 hour. A typical scenario was for a rider to check the on-demand flow first when they’re about to leave, but decide to schedule a ride instead due to high fare or long estimated time of arrival.

Problem | Inconsistent representation of “time”

In addition to the problem of the branched flow, the representations of “time” in the existing UI were also inconsistent and scattered throughout the app. Different product teams were launching features regarding waiting time without a central place for user to specify their desired pickup time.

Proposal | Seamless integration between two user intents

Around the same time, the core team also recognized the exploding features on the Request screen and were in the middle of a major redesign. I took advantage of this chance to build on top of the new framework, focusing on how we might give users better control of “time.”

After a few round of iterations, the final proposal was carried forward by the core team. The key highlights were:

• Give users control to specify pickup or arrival time
• Provide a seamless transition between on-demand rides and scheduled rides via the time picker
• Integrate “time” with pickup location or drop-off destination to avoid confusion